The world wide web has become a popular medium to access information. Utilizing Internet protocols, users simply point their web browser to a specified uniform resource location (URL) or Web address to download a Web page from the Internet. The Web page will be retrieved from a Web server, downloaded onto their browser and rendered in a viewable format, to be viewed and enjoyed by the user.
In addition to the Web server, certain application servers cooperate with the Web server to assist in serving and rendering the content. Application servers are also involved in other functions such as routing requests, acting on requests, and rendering documents to be sent back to the client.
The popularity of Web pages has created different methods to access and serve up Web pages. However, despite the popularity of accessing Web sites, the methods used to access Web data have a number of shortcomings.
Often in Web applications, there is no single source for the URL definition, syntax and parameters. One approach to address this shortcoming is to code URLs into source files. However, this method is prone to error and results in complicated logic within the service to handle numerous exception cases. It is also difficult for a developer to know, based on the incoming URL, how the request is routed through the system and which module should respond to the request.
A second shortcoming is that there is no control over the parameters passed to a request handler. This causes a similar problem to that mentioned above. As more functionality is needed, further parameters are added to the query string in one location and forgotten in others, resulting in complex logic to validate incoming parameters.
A third shortcoming relates to the use of monolithic request handlers having convoluted logic. In many Web applications, there is no real hierarchy of functionality. Requests are lumped together into common categories and then sent to the appropriate handler. The handler has to be able to handle any one of these requests. Over time, the code in these handlers can grow to the extent that they become difficult to manage.
A fourth shortcoming is that there are often multiple ways to work around a defined scheme. Since there is no enforceable definition of a URL scheme, it is the developer's responsibility to maintain his code correctly and efficiently. In due time, the URL formats would diverge, making it difficult to understand and maintain the application.
Another shortcoming is the lack of defined control flow through the system. Control flow through the system would quickly become very convoluted as developers, needing functionality in another handler, begin to call other handlers directly. Often times, the response from the called handler would be either returned to the caller, or modified, and passed to another handler. The data being passed into the system would be modified as it moves through the system, making it difficult to understand.
A further shortcoming relates to passing parameters that are not classified or typed into an HTTP request. The resulting logic required to validate each parameter can be cumbersome and is subject to the interpretation of the developer writing the code. This may also lead to misunderstanding or confusion.
Yet another shortcoming relates to the short interval of request timeouts. Attempting to solve this problem without a single point of control would result in complex, error-prone code.